The shape analysis takes once the mindset is in place
Three cards on what shape analysis takes
Three reasoning modes — deductive, inductive, abductive — and why using the wrong one for the problem produces sophisticated answers to questions that were never asked.
Why most analytical errors are structural, not technical — and how mutually exclusive, collectively exhaustive decomposition prevents the overlaps and gaps that downstream tools cannot fix.
The bridge from thinking to measuring. How concepts become variables and variables become testable claims — and why structure alone never produces findings on its own.
Tool-first analysis fails not because the tool is wrong — but because the question asked of it was never the question the tool can answer.
Critical source of analytical failure: applying the wrong type of reasoning to a business problem
Rules and relationships are known in advance. The analyst tests whether a specific hypothesis holds. General principle → specific case. Highest certainty.
No predefined categories. The analyst lets patterns emerge from data. Specific observations → general patterns. Provisional certainty.
An outcome is observed; the cause is unclear. The analyst weighs competing explanations and chooses the most plausible. Observed effect → inferred cause. Lowest inherent certainty.
An operator believes its 15% loyalty discount drives a meaningful reduction in churn among price-sensitive prepaid subscribers.
→ The hypothesis is explicit: Offer → churn reduction.
→ The variables are defined: Offer applied (yes/no), 90-day churn, subscriber segment.
→ The test is straightforward: Compare churn in segments that received the offer against those that did not, controlling for the seasonal baseline.
The analyst is not discovering anything new about how the business works; they are testing whether a specific belief holds. This is a deductive question.
An operator has not previously categorised its subscriber base in any structured way.
→ The analyst is asked: "Are there natural groupings of subscribers we should be aware of?"
→ The analyst applies clustering techniques to behavioural and usage data.
→ Discovers, three meaningful groups: high-data power users, intermittent voice-only users, and a previously invisible segment of dormant SIMs that still recharge.
None of these segments was specified in advance. They emerged from the data. The output is a hypothesis about how subscribers naturally group — not a tested fact.This is an inductive question.
An operator observes that 90-day retention dropped sharply for the subscriber cohort acquired in March.
→ Multiple plausible explanations exist.
→ The analyst compares several competing explanations and eliminates those that do not fit the observed pattern.
→ The acquisition campaign remains the explanation most consistent with the available evidence.
→ This does not prove causation, but it provides the strongest working explanation.
This is not proof. It is an inference. "the explanation most consistent with the evidence," not as "the cause."
· Click to place points · Random Points are uniformly scattered · Colored regions = service territories · Boundary line = equal distance between teams ·
This demo shows how clustering can test whether initialy set administrative regions are operationally efficient, where teams may be overloaded, and where service hubs or spare parts may need repositioning.
Watch maintenance teams / service hubs (★) reposition each step. The colored regions are service territories — every area belongs to its nearest maintenance team. The boundary line shows equal travel distance between two teams. Towers on one side are closer to one team; towers on the other side are closer to another. As teams move, service territories shift too.
· Blue circles = ε-neighborhoods of core points · Cluster colors = DBSCAN clusters · Thick outline = core point · Red X = noise ·
DBSCAN does not use centroids and does not require choosing K. Instead, it searches for dense neighborhoods.
Notice that some points remain unclustered. DBSCAN allows: "this point does not belong to any dense structure." Those observations become noise points.
Noise points may represent anomalies, fraud, abnormal network behavior, isolated customers, or rare operational events. However, DBSCAN only says "unusual relative to dense patterns" — business logic decides whether it is truly problematic.
The three modes do not produce equally strong conclusions
The three modes do not produce equally strong conclusions
| Mode | Tool family | What it can — and cannot — do |
|---|---|---|
| Deductive | Hypothesis tests, regression models, statistical comparisons, A/B tests, controlled experiments | Can test specified relationships against data.
Cannot discover relationships that were not specified in advance. |
| Inductive | Clustering techniques, exploratory decision trees, dimensionality reduction, association rule mining | Can surface patterns, segments, or rules from the data.
Cannot prove causality or confirm patterns will persist. |
| Abductive | Hypothesis synthesis, causal logic, comparative case reasoning, system understanding — supported by data, not replaced by it | Can structure the reasoning behind a best-explanation inference.
No single algorithm produces abductive conclusions; they emerge from disciplined judgment. |
Most analytical errors are structural, not technical
A single underlying driver shows up under multiple categories, getting counted twice and inflating its apparent importance.
We sees two large drivers when there is only one.
A driver is excluded from the structure, leaving an entire region of the problem unexamined.
The blind spot is not visible from inside the analysis.
The picture feels complete because it was complete from a limited frame.
Most analytical errors are structural, not technical
| Failure | Where it shows up in this list |
|---|---|
| Overlap (not mutually exclusive) | "Customer dissatisfaction" overlaps with "product issues," "pricing changes," and "sales team effectiveness" — any of these could cause dissatisfaction. The same revenue effect could be assigned to multiple categories depending on framing. |
| Gaps (not collectively exhaustive) | Where do channel mix shifts go? Where does seasonality fit? What about changes in subscriber composition The same number of subscribers but a different mix? None of these have a clear home, so they will likely be missed entirely. |
Mutually Exclusive · Collectively Exhaustive Non-negotiable Requirements
The boundaries are clean.
Nothing relevant is missing.
Not overlapping, but share a fuzzy boundary "operational issues" and "process problems"
Categories at different levels of detail — "pricing," "marketing,"and "South region"
A final "other" category added to feel exhaustive.
For each branch, decide whether it's clean or which trap it falls into. Then identify what's missing from the structure as a whole.
Clean structure usually comes from underlying logic
Clean structure usually comes from underlying logic
Initial structures are rarely perfect. The first attempt usually contains overlaps, gaps, or both. This is not a failure of skill — it is the natural result of working on complex problems. Three questions drive each refinement:
If a real example fits more than one category, the structure must be revised.
If I imagine an unexpected explanation, where would it go? If there is no place for it, the structure is not exhaustive.
If some categories are causes and others symptoms, the structure mixes layers. Re-anchor at one level.
Clean structure usually comes from underlying logic
At this stage, the only legitimate tools are logical decomposition methods. They don't produce numbers; they produce structure.
| Tool | What it does | When to use |
|---|---|---|
| Issue trees | Hierarchical decomposition of a problem into progressively more specific sub-questions or drivers. | A complex business question must be broken into investigable parts. |
| Logic trees | Decomposition driven by the logical structure of the problem ("what must be true for X to occur?"). | The analyst needs to map conditions that could produce an outcome. |
| Driver frameworks | Pre-built structures decomposing specific outcomes (revenue, ARPU, subscriber value) into mathematical components. | A well-understood outcome needs analysis and an established decomposition exists. |
Bridge to analysis is the conversion of concepts into variables and hypotheses.
| Category | What it is | What it produces |
|---|---|---|
| Concept | An idea, theme, or area of concern. Usually a noun phrase. "subscriber satisfaction," "network quality," "market position." | Discussion. Concepts can be debated but not measured directly — they name the thing of interest without specifying how to observe it. |
| Variable | A measurable expression of a concept. Specifies unit, source, time frame, boundary. "NPS from quarterly survey," "dropped-call rate per cell site." | Numbers. Variables produce data — tracked, compared across periods or segments, aggregated. They convert ideas into observations. |
| Hypothesis | A specific, testable claim about how variables relate or differ between groups. "App users have lower 90-day churn than non-users." | Findings. Hypotheses can be confirmed, rejected, or partially supported. They make analysis directional and decisional. |
Concepts come from the issue tree. Variables come from translating concepts into measurement. Hypotheses come from connecting variables in claims that can be tested.
Each stage adds specificity. By the end, the analyst knows exactly what data to pull, what comparison to make, and what answer would settle the question.
| Stage | Statement | Status |
|---|---|---|
| Concept (raw) | "Subscriber satisfaction" | Discussion-level only. No measurement defined. Cannot be analysed yet. |
| Concept (refined) | "Satisfaction with the service experience over the past 90 days" | Discussion-level, but specific. Tells us what to measure conceptually, not how. |
| Variables | Quarterly NPS (survey-based) · monthly support-ticket rate per active account · 90-day app-engagement retention | Measurable, but not yet investigative. We can track these, but have not stated what we expect or want to test. |
| Hypothesis | "Accounts with NPS < 7 in the past two quarters have ≥ 3x the 90-day churn rate of accounts with NPS ≥ 7, after controlling for tenure and ARPU." | Testable. An analytical claim that can be confirmed, rejected, or refined with data. |
Each stage adds specificity.To Know What data to pull, what comparison to make, and what answer to settle the question.
Stop at the concept level — "subscriber satisfaction" — produces a deck of charts about NPS trends and support tickets. The conclusions stay vague: "NPS has declined," "tickets are up." Stakeholders nod. Nothing specific is decided.
Produces a finding with an explicit hypothesis: "Low-NPS accounts churn at three times the rate of high-NPS accounts; addressing satisfaction in this segment is worth ~$X in retained revenue." The first analyst described the situation. The second answered a question that drives action.
The relationship is named precisely.
Vague claims ("X may relate to Y") do not qualify.
Directional, magnitude-bearing claims do.
The hypothesis can be wrong.
There must be evidence that, if observed, would force rejection.
A claim that cannot be wrong is a belief, not a hypothesis.
The hypothesis traces back to a specific branch of the MECE issue tree.
The analytical expression of a particular driver.
Select the best variable definition, then select the best hypothesis.
The inferential methods become legitimate for the first time.
Once structure has been translated into variables and hypotheses, formal analytical tools become legitimate for the first time — because there is now something concrete for those tools to operate on. Variables have been defined. Hypotheses have been articulated. The analyst can finally select methods designed to test specific claims rather than to explore unstructured data.
| Method | What it does |
|---|---|
| Descriptive statistics | Means, medians, distributions that characterise each variable — foundational before testing relationships. |
| Comparisons across segments / periods | Side-by-side examinations that test whether differences exist between groups — the simplest hypothesis test. |
| Regression models | Quantify relationships, control for confounders, test directional claims. Appropriate when hypotheses are specific. |
| Classification techniques | Predict category membership from input variables. A tool of prediction, not discovery — see Card D. |
| Hypothesis tests | Formal statistical tests that quantify the strength of evidence for or against a specific claim. |
The inferential methods become legitimate for the first time.
Tool choice is subordinate to variable definition. No method can compensate for poorly defined variables. A regression on vague variables produces vague results dressed up as precise ones.
Conversely, well-defined variables enable multiple methods appropriately.
Disciplined definition expands the range of legitimate methods. Sloppy definition collapses it.
Five questions to consolidate what you've learned across Cards D, E, and F. Select the best answer.
Five questions to consolidate what you've learned across Cards D, E, and F. Select the best answer.
Five questions to consolidate what you've learned across Cards D, E, and F. Select the best answer.
You've worked through the full Skeleton module — the reasoning-mode discipline of Card D, the structural rigour of MECE in Card E, and the conversion from structure to analysis in Card F. The tool legitimacy ladder has now opened up to inferential methods — but only because you've built the discipline upstream that makes those tools trustworthy. Module 03 takes the hypotheses developed here and teaches the discipline of testing them well.
Five questions to consolidate what you've learned across Cards D, E, and F. Select the best answer.
Five questions to consolidate what you've learned across Cards D, E, and F. Select the best answer.
You've worked through the full Skeleton module — the reasoning-mode discipline of Card D, the structural rigour of MECE in Card E, and the conversion from structure to analysis in Card F. The tool legitimacy ladder has now opened up to inferential methods — but only because you've built the discipline upstream that makes those tools trustworthy. Module 03 takes the hypotheses developed here and teaches the discipline of testing them well.